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ABSTRACT 



An electronic whiteboard is coupled to a computer which 
receives information from the whiteboard indicative of 
graphical user inputs entered via a writing region of the 
whiteboard and control inputs entered via a control region of 
the whiteboard. A driver executing on the computer receives 
the information transmitted by the whiteboard performs 
certain actions on the received information and causes an 
application program. to retrieve the information and store the 
information to a session file. The application provides a user 
interface which allows a user to view images generated on 
the whiteboard, store such images, view previously stored 
images and to manipulate the images in a variety of ways. 

15 Claims, 7 Drawing Sheets 



20- 



55- 





29 J 


^-51 (ENTER) 


2g<E!JS> 


27 K a| 



10 



18 



14 





C_24 



25 



09/20/2002, EAST Version: 1.03.0002 




09/20/2002, EAST Version: 1.03.0002 



U.S. Patent Aug. 4, 1998 Sheet 2 of 7 5,790,114 




09/20/2002, EAST Version: 1.03.0002 



U.S. Patent Aug. 4, 1998 Sheet 3 of 7 5,790,114 




09/20/2002, EAST Version: 1.03.0002 



U.S. Patent Aug. 4, 1998 Sheet 4 of 7 



FIG. 4 



Application 
Viewing 
Recording 
File Services 





Shared 
Memory 
Ring Buffer/ 



Serial Port 



70 



10- 



Whiteboard 




09/20/2002, EAST Version: 1.03.0002 



U.S. Patent 



Aug. 4, 1998 Sheet 5 of 7 

FIG. 5 



5,790, 



Header Block 


76 


Index Bloc 


c 


77 



Index Block Information 



Index Entry 1 



Attributes 



Location of data 



Location of snapshot 



Location of n&me 



Index Entiy N 



Attributes 



Location of data 



Location of snapshot 



Location of name 



Data Block 78 



Data points and events 



Index Block 22 



More index entries 



Data Block 2£ 



Data points and events 



Data Block 25 



Data points and events 



Index Block 22 



More index entries 



Index Block 22 



More index entries 



09/20/2002, EAST Version: 1.03.0002 



U.S. Patent 



Aug. 4, 1998 Sheet 6 of 7 



FIG. 6 



5,790,114 




Store Event 
to Buffer 




09/20/2002, EAST Version: 1.03.0002 



U.S. Patent Aug. 4, 1998 Sheet 7 of 7 5,790 




09/20/2002, EAST Version: 1.03.0002 



5.790.114 

1 2 

ELECTRONIC WHITEBOARD WITH MULTI- viousiy stored session files may be retrieved to view, print 

FUNCTIONAL USER INTERFACE and/or copy pages to other applications and to store. 

manipulate, display and print the information. The foregoing 
functions are preferably provided by whiteboard application 

AUTHORIZATION 5 software operating on the PC 

. * ... j. , . , The whiteboard application software implements a 

A portion of the disclosure of this patent document rcC order function which operates to allow graphical user 

contains material which is subject to copyright protection. j nput s and certain commands entered via the whiteboard to 

The copyright owner has no objection to the facsimile ^ stored ta a whiteboard session file, which is a recording 

rcproducuonbyaiiyon^ of aU activity on the wWteboard since the fiie was created 

disclosure, as it appears in the Patent and Trademark Office The user may organize the recording of whiteboard activity 

patent file or records, but otherwise reserves all copyrights by &<M ping certain activities in the same or different files or 

whatsoever. alternatively, by storing all activities in a single file. 

1. Held of the Invention A snapshot may be created either by the user or automati- 
This invention relates generally to the field of user 15 cally by the application software to allow creation of an 

friendly electronic input devices for use with general pur- image which is the composite of all graphical user inputs 
pose computers. from a first marker inserted in the session file to a second, 

2. Background subsequent, marker inserted in the session file. The appli- 

Whiteboards are a well known medium to facilitate per- c * ti ? D software im P lemeDts a t0 *U 

sonal thoughts and group discussions by providing a con- 20 of sn ^ shots 1x1 a scssion me t0 a 110 * selection, 

venient surface upon which notes, drawings, charts, or other viewi ° E and ^P" 1 ^™ • particular snapshot For 

notations may be made. As with the traditional chalkboard, instance < 3 SDa P shot ™y selected, viewed and moved or 

whiteboards allow notations to be made in multiple colors copied from one session me to aDOlher - 10 a 

and to then be erased. Whiteboards offer several advantages sna P shot ^ selected and exported in a selected data file 

over chalkboards including a clean white surface which 25 format for mam P u]ation *>y another application program, 

provides for greater contrast over the traditional green Advantageously, the sequence in which graphical user 

background of chalkboards. In addition, writing on a white- mputs ^ entered, together with time information indicative 

board is easier for many than on the traditional chalkboard. of mc tcm P onJ relationship in which the inputs are entered. 

For example, the smooth writing surface of the whiteboard ** c SUxcd m t0 sub sequent viewing of the 

allows easy use of the erasable felt tip markers used on 30 manncr m which mc "P" 48 were entered and ^° t0 

whiteboards, whereas the chalkboard surface provides a f 6 ^* of mdividual erasure strokes. As used 

somewhat scratchy surface to hold the chalk used for writing hercm * ^ Xerm " stroke * te to mean me points 

on such surfaces. In addition, many users prefer a white- g encratcd frora the time a marker or other instrument such 

board to a chalkboard simply because the marker may be 35 a human hn & 1 °* 311 erascr is Fussed upon the writing 

gripped easier than chalk and does not mark the user's hand 35 surfacc of mc whiteboard with sufficient pressure to cause 

when gripped transmission of data from the whiteboard to the PC to thc 

Recently, whiteboards have been developed to allow the ^^^J^^J^J 0 T ***** 

user writings and notations entered upon 2e whiteboard to ^^^^^^V^'a^J^Z^ 

u ^ ncrn :^^A t ^ ^ A 1 * * Tv , contacting any edge of the whiteboard. In addition, nothing 

be transmitted to a digital computer for storage, display and Aft * A «. ^ . .„ . . ... . , 6 

„ c „ . j . „ - v*oyi<*y auu the user can do at the whiteboard will cause data to be 

3 S tL l 7> t° W h ^T* *** ***™ removed from the session file. Of course files can be deleted 

£ * uiewmteboardtobesavedin the computer, to be in mc nonnal ^ mc rc 

displayed, to be printed, transmitted or manipulated. While ™ 7T ^ !L * L* . 

such devices increase the versatility and usability of the J** 1 * a^hcation sofrware^erablv receives information 

traditional whiteboard, a need continues to exist for a traDSmittcd fro x m mc whiteboard by way of a driver which 

whiteboard which improves upon the mechanisms to enter 45 L'fT » /"J™* 1 ™ bit-stream, formatted as packets, 

images and notations into a computer via the whiteboard ?° m P*^*™ a ? f Unctions on 

and which allows for subsequent operations to be performed f° KC ?™* ^formation to a buffer 

on thc stored data received from the whiteboard. retne ^ by me application software. For example, the 

driver performs certain error checking functions on the 

SUMMARY OF THE INVENTION 50 received bit-stream and discards packets determined to be 

. corrupted. The application software advantageously inserts a 

ft is a rmnciple object of the present invention to provide pen-up command, which indicates that the marker, or eraser, 

a whiteboard which enhances the ability to create, retain and used by the user has been lifted off of the whiteboard writing 

review information. In a ^ciple aspect of the present surface, to avoid a phenomena known as streaking, where 

invention, a whiteboard is coupled to a general purpose 55 the corrupted packet, discarded by the driver, may have 

digital computer (personal computer or PC) to allow any contained a pen-up command. 

writings, drawings or other notations (collectively "graphi- 71lcse ^ ^ fcaturcs aQd advanlagcs of mc invcntion 

cal user inputs^ made on the whiteboard to be displayed on will be better understood by considering the following 

a monitor coupled to the computer. The graphical user inputs detailed description, 

are also stored in the computer for subsequent retrieval, eo 

manipulation, and printing. Previously stored material may BRIEF DESCRIPTION OF THE DRAWINGS 

be subsequently reviewed at the user's convenience. Erasure FIG. 1 is a schematic block diagram of a preferred 

of the inputs are also captured and stored. embodiment; 

Advantageously, whiteboard systems operating in accor- FIG. 2 is a schematic representation of the information 

dance with the present invention allow a user to work with 65 flow in the system of FIG. 1; 

thc whiteboard in two ways. First, graphical user inputs may FIG. 3 is a block diagram of the major components of a 

be stored into a file for subsequent retrieval. Second, pre- controller contained in the whiteboard of FIG. 1; 
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FIG. 4 is a schematic representation of the major func- 
tional components of the software application executed by 
the computer of FIG. 1 ; 

FIG. 5 is a block diagram of the session file of FIG. 4; 

FIG. 6 is a flow chart showing operation of a portion of 
the software application of FIG. 3; and 

FIG. 7 is a schematic block diagram of an alternative 
implementation of the whiteboard application software of 
FIG- 1. 

DETAILED DESCRIPTION 

L Overview 

FIG. 1 of the drawings shows a preferred embodiment 
which includes a whiteboard 10 coupled to a general pur- 
pose desktop computer 12. The desktop computer preferably 
takes the form of a personal computer (PC) which operates 
die Windows95™ or the Windows 3.1™ operating system, 
both of which are available from the Microsoft Corporation. 
Redmond. Wash. The whiteboard 10 preferably employs 
conventional resistive membrane technology responsive to 
pressure applied upon whiteboard writing surface 14. In 
response to an input applied by pressing upon the white- 
board writing surface 14. two voltages, indicative of an x 
and y coordinate of the input are generated for use by a 
controller (shown in FIG. 2) which converts the two analog 
voltages into digital coordinates for transmission to the PC 
12 which includes a display 13 and is coupled to a printer 15. 
The PC is also coupled to a printing device and other input 
devices such as a mouse 17 and keyboard 19 to receive 
inputs for controlling and initiating different functions on the 
PC. The controller preferably recognizes user inputs applied 
in a writing region 18 of the whiteboard as graphical input 
data, and user inputs applied in a button region 20 of the 
whiteboard as command inputs corresponding to one of a 
plurality of commands, for transmitting control information 
which is either stored by the PC or interpreted by the PC to 
execute a predefined function. FIG. 1 shows at 23 an image 
which may be created by way of marker 24 upon the writing 
region 18. When new images are desired to be created, 
eraser 25 may be used to erase the image 23 from the writing 
region 18. The eraser 25 is advantageously circular in shape 
to allow far a plurality of erasing functions as described in 
greater detail herein. 

The whiteboard 10 also includes a speaker 48 for trans- 
mission of audible information to alert the user as to 
particular actions being performed on the whiteboard and for 
other status information. A visual indication in the form of 
a Light Emitting Diode (LED) 46 is also provided to indicate 
to the user that power to the whiteboard is being supplied 
through power cord 49 and that the whiteboard is opera- 
tional. 

The button or control region 20 preferably includes the 
following buttons which may be touched by the user with 
either a finger or by use of a marker 24 to cause transmission 
of a signal by the controller 16 which is indicative of the 
desired command to the PC: (a) four pen color buttons 
including red green, blue and black, (b) a narrow erase 
button, (c ) a wide erase button, (d) a snapshot/erase all 
button, (e) a snapshot button, (f) a print button, and (g) a 
show board button. A more detailed explanation of the 
functions performed by each of these buttons is provided 
below. 

The PC 12 preferably has stored therein, the aforemen- 
tioned whiteboard application software which implements a 
recorder function for recording user input data entered via 
the whiteboard surface 14. and a viewer function for dis- 
playing and allowing manipulation of the recorded data. An 



4 

enlarged view of the display 13 is shown in FIG. 1 at 55. The 
application software, provides and accepts information via 
an easy to use Graphical User Interface (GUI). 
As seen at 55. the display 55 displays the viewer within 
5 a window which preferably contains three regions: a selec- 
tion region 27. a current board region 28 and a snapshot 
region 29. Selection region 27 displays, as shown at 30. an 
image which the user has selected for display. The image in 
region 27 may be either an image which has been previously 
ia entered and stored, or may be an image representative of 
inputs currently being entered onto the whiteboard Current 
board region 28 displays an image representative of inputs 
currently being entered onto the whiteboard. Thus, if the 
user has selected the current image for display in the 
is selection region men the selection region 27 and the current 
image region 28 will show the same image. Snapshot region 
29 contains a reduced size version of each snapshot con- 
tained in the currently open session file. A scroll bar with 
buttons such as seen at 51 allows the user to scroll up or 
20 down through the images to select an image. Once selected, 
the image is displayed in selection region 27. 

FIG. 2 of the drawings shows the logical flow of infor- 
mation from the whiteboard 10 to the PC 12. Graphical user 
inputs generated via the writing region 18 and the control 
25 region 20 are transmitted to the controller which generates 
a stream of data packets, one of which is seen at 60. for 
transmission to the PC 12. A driver 62 executed by the PC 
receives the data packets 60. performs certain error checking 
and other functions on the data, and an application program 
30 64 executed by the PC receives the data from the driver, 
eliminates redundant data and stores the data to a session file 
66. The data packet is formatted in a manner explained in 
further detail below in connection with the Format Tablet 
command implemented by the controller. The session file is 
35 formatted in a manner more fully explained in connection 
with FIG. 5. 
H Whiteboard 

The whiteboard 10 may take a variety of sizes depending 
on the location in which it is to be used. For instance, a 
AO preferred embodiment has dimensions of 24x36 inches to 
allow use in an office or cubicle by an individual user. 
Whiteboards of larger sizes may find use in conference 
rooms or meeting areas for use during group discussions. As 
noted above, the whiteboard preferably employs a sensor 
45 using resistive membrane technology to detect the position 
of user inputs on the writing surface 14. While any one of a 
number of technologies may be employed to detect the user 
inputs, resistive membrane technology has been found to 
have a number for advantages including durability, 
so reliability, relatively low cost In addition, resistive mem- 
brane technology allows rnaniifactiiring simplicity. 

The writing surface 14 advantageously allows the use of 
conventional erasable felt-tip markers such as seen at 24. 
The writing region 18 of the whiteboard is white and thus 
55 provides a high degree of contrast with most colors of 
markers. The writing surface 14 may be erased and cleaned 
by an eraser 25 which facilitates the erasure of the white- 
board in a manner to be explained, or by most other 
conventional disposable towels, tissues etc. 
60 The sensor is located under the writing surface of the 
whiteboard. It consists of two sheets of material mat are 
physically separated by tension. Each sheet is coated with a 
conductive film and electrical contacts are made to the upper 
and lower edges of the bottom (Y) sheet and to the left and 
65 right edges of the top (X) sheet These four contacts are 
connected via wires to the controller (shown in FIG. 2 and 
described in greater detail below). Writing on the surface is 



40 



09/20/2002, EAST Version: 1.03.0002 



5,790,1 14 



5 

sensed by applying sufficient force to cause the two resistive 
coatings to come into contact with each other. The sheets act 
as resistance dividers and a voltage gradient is created by 
applying different voltages to the edges of one sheet. The 
voltage at the point of contact is induced onto the sheet that 
is not powered This voltage is directly proportional to the 
location of contact on the powered sheet If, for example, the 
contact point is X A of the way over from the left edge of the 
sensor and Vx the way up from the bottom edge, the voltages 
describing the exact location of contact could be expressed 
in coordinate form as follows: 

coordinate is (Wxgractf, Wxgradr) 

where, 

gradX=right edge drive voltage — left edge drive voltage 
gradY =*op edge drive voltage — bottom edge drive volt- 
age 

With the right and top drive voltages set to 5V. and the left 
and bottom voltages set to 0V. the coordinate reduces to 
(1.25. 2.5). 

Whiteboard Function Keys 

The whiteboard is designed with function keys, or buttons 
20 around the outside perimeter to allow the user to transact 
most normal drawing activities directly from the board. The 
application supports decoding and processing of these func- 
tion keys as needed and described herein: 
red pen Change the current draw color to red 
black pen Change the current draw color to black 
green pen Change the current draw color to green 
blue pen Change the current draw color to blue 
narrow erase Erase a narrow region around the current 
draw position 

wide erase Erase a wide region around the current draw 
position 

snapshot/erase all Erase the whole board and insert a 
bookmark to save the current image as a snapshot 

print Print a copy of the current image 

snapshot Insert a bookmark to save the current image as 
a snapshot 

Show Board Restores the viewer window to foreground 
focus, 
m. Controller 

FIG. 3 of the drawings shows a logical block diagram of 
the components in the controller 16. The controller employs 
a conventional microprocessor 28 to implement the func- 
tions performed by the controller by way of a program stored 
in ROM 34. An Analog-to- Digital (A/D) converter 36 con- 
verts analog signals received from whiteboard sensor 30 into 
digital information for processing by the microprocessor 28. 
A Non- Volatile Random Access Memory (NOVRAM) 38 
stores configuration information. A sensor control module 
40 responds to control signals from microprocessor 28 to 
provide appropriate analog signals to the sensor 30 and to 
receive electrical signals in the form of analog signals from 
the sensor 30. A touch detect circuit 44 informs micropro- 
cessor 28 each time a new touch is detected on the sensor 30. 
by checking for initial contact and verifying that contact is 
being maintained. The controller also includes a Light- 
Emitting Diode (LED) 46 and a speaker 48 for generation of 
visual and audible information. An RS-232 interface 50 
provides a serial link between the controller and the PC. Hie 
microcontroller 28 is responsible for coordinating all activ- 
ity of the controller. It takes sensor data from the A/D 
converter, calculates touch coordinates, filters coordinate 
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data, sends the data to the outside world, and decodes 
messages from, and sends messages to. the outside world. 

As previously noted, the controller receives two- 
dimensional positional information by way of four wires 

5 coupled to whiteboard resistive membrane sensor assembly 
30. As seen, the sensor 30 includes a top sheet 31. and a 
bottom sheet 32. The exterior surface of the top sheet 31 
corresponds to the writing surface 14. The wires coupled to 
the sheets 31 and 32 are alternately used to provide electrical 

io energy to one sheet and to detect a user input with the 
opposing sheet by detecting the voltage at the location which 
is pressed by the user. 

The controller implements a set of functions which are 
executed upon appropriate request by driver software 

15 executed by the PC 12. Each of the functions implemented 
by the controller is described individually below. 
Audio Tone Request 

The controller provides audible warnings via LED 46 to 
the user. This function is selected by a host command which 

20 takes the following format: 

<SOH>ATx<CR> 

where. SOH and CR are qualifiers. SOU (Start Of Header) 
is a qualifier which indicates that the following data is meant 
25 to be interpreted as a command. CR is a terminator for a 
command. When the controller receives CR it then knows 
that the command being received has been received. X is a 
variable which specifies a unique sound. The sounds pref- 
erably include a click, a beep, a fanfare sound, a flop and a 
30 hum. A click is a single tone of very short duration. A beep 
is a single tone of approximately 0.125 sec duration and of 
mid to high frequency. A fanfare sound is a series of three 
beeps, each incrementing in frequency from the previous. A 
flop is a series of three beeps, each decreasing in frequency 
35 from the previous. A hum is a low frequency tone which is 
continuous during touch. Any one of the foregoing sounds 
may be produced in response to events including 
touchdown, erase, button touch and button touch fault. 
Calibrate Extended 
40 Syntax: <SOH>CX<CR> 

Description: Initiates an interactive, two-point calibration of 
the touchscreen, to allow for calibration of the size of the 
active area of the touchscreen. As used herein, the term 
"active area** refers to a rectangular area on the touch- 
es screen which may be contacted by a touch device to cause 
transmission of positional digital values indicative of the 
position of the contact of the touch device. Contact of a 
touch device outside of the active area is ignored by the 
controller. 

50 The calibration points (targets) arc set inward from the 
comer of the video image provided by the touchscreen for 
accuracy and ease of operation. During calibration, the 
active area of the touch screen is defined by mapping 
locations to an absolute X. Y coordinate system. Two target 
55 areas on the screen are touched which sends the X. Y 
coordinates for those touch points to the controller. The 
controller calculates all other touch points based on these 
two values. 
Finger Only 
60 Syntax: <SOH>FO<CR> 

Description: Causes the controller to accept only finger (Le. 
marker or finger) input and is the default mode when 
using a resistive membrane whiteboard. If a whiteboard 
employing sensor technology which allows use of a 
65 special pen electrically coupled to the whiteboard sensor 
is use. then the controller may operate to accept inputs via 
different devices which may have different electrical 



09/20/2002, EAST Version: 1.03.0002 



5.790.114 



<7-bytr-pacLetx7 -bytc-packct> . . . <7-bytc-pactct> . 

TABLE 1 



Byte Bits 0-7 



bO~b3: Drive level (amount of signxi seal from ccmtrolkr) 

M: Reserved 

t>S: Reserved 

b6: Reserved 

b7: Synchronization bit (Always 1) 

bO-b2: 3 most significant bits of upper left (UL) comer 

b3: Always 0 

b4-b6: 3 most significant bits of tower left (LL) corner 

b7: Always 0 



10 



15 



20 



25 



interactions with the whiteboard sensor. As described in 
V S. patent application Ser, No. 08/503343 entitled "A 
Touchscreen Controller with Pen and/or Finger Inputs", 
such a feature advantageously allows the controller to 
determine what type of input device is being used. 
However, for a resistive membrane whiteboard, there is 
no direct electrical interaction between the sensor and the 
input device because the writing surface 18 electrically 
insulates the input device from the sensor. The following 
description is applicable however should the whiteboard 
take the form of a capacitive sensor such as described in 
the aforementioned '539 patent Wilh such devices, the 
controller can ignore pen input and can offer three touch 
device inputs: 

(1) Pen or Finger mode detects pen and finger contact, 
giving priority to pen contact when both are detected. 

(2) Finger Only mode detects finger contact only and 
processes finger coordinate data. 

(3) Pen Only mode detects pen contact only and processes 
pen coordinate data. 

This setting changes back to the default setting at power- 
up. or if a Restore Defaults command is issued. If the default 
setting in the controller data block 1 has been changed, this 
setting only changes back to the default setting with a 
Restore Defaults command. 

Response: <SOH>0<CR> Positive response. 
Format Raw 

Syntax: <SOH>FR<CR> 
Description: This command is used primarily for diagnos- ^ 
tics. It causes the controller to return the signal level 
(amount of touch) of each of the four whiteboard comers 
in digital format. The returned values are not corrected for 
offset and stray values. However, the offset and stray 
values may be obtained using the Get Parameter Block 
command. The Format Raw data is a 7-byte packet that 
includes 1 status byte and 6 bytes of binary corner data. 
The data format for the packet is advantageously fixed in 
order to provide the most efficient transfer of data. The 
first byte of each packet always has its high bit (Bit 7) set ^ 
to provide synchronization with the host system. Data is 
returned in 10-bits. which are delivered in two bytes. 
To use Format Raw. the controller and host PC must be in 
an 8-bit data communication mode. A Reset command must 
be issued to terminate format Raw The controller may return 45 
several bytes of data between the time a Reset command is 
issued and when the controller receives the Reset command. 
A continuous scan can be performed for the Reset acknowl- 
edgment or a second Reset after approximately 10 seconds 
has passed may be issued. 
Response: <SOH>0<CR> Positive response. 
After the controller is in Fomat Raw mode, the controller 
continuously outputs data in the following format: 



50 



8 



TABLE 1 -continued 



Byte 


Bits 0-7 




3 


bO-b2: 


3 most significant bits of lower right (LR) corner 




b3: 


Always 0 




b4-b6: 


3 most significant bits of upper right (UR) comer 




b7: 


Always 0 


4 


bO-b6: 


7 least significant bits of lower left (LL) corner 




b7: 


Always 0 


5 


bO~b6: 


7 least rignitVanr bits of upper left (UL) comer 




b7: 


Always 0 


6 


b0-b6: 


7 least significant bits of upper right (UR) comer 




b7: 


Always 0 


7 


bO-b6: 


7 least significant bits of lower right (LR) comer 




b7: 


Always 0 



Format Tablet 

Syntax: <SOH>FT<CR> 

Description: This is the default format and is the only format 
in which data is transmitted. This command causes the 
controller to output the X. Y touch coordinate data in a 
5 -byte packet TTie packet includes 1 status byte and 4 
bytes of binary X, Y coordinate data. The protocol also 
establishes the X and Y coordinate output as 14 binary bits 
providing a range of 0 to 16383. The low order bits 
(XJ-X0 and Y3-Y0) in a 1024 by 1024 touch screen are 
not significant because data can fluctuate with each touch, 
and therefore may not be completely accurate. To use 
Format Tablet, the controller and host system must be in 
an 8-bit data communication mode. 
Response: <SOH>>cCR> Positive response. 
After the controller is in Format Tablet mode, touching 

the screen causes the controller to return a response in the 

following format: 



35 



SxxYy 

S=Status byte; first byte of data. Refer to Table 2 below 
which defines the status bits (Byte 1) for the Format 
Tablet data. 

Xx=X(horizontal) coordinate data; second and third bytes 
of data. 

Yy=Y(vertical) coordinate data; fourth and firm bytes of 
data. 



Data 



MSB* 



Bits 



LSB* 



Sequence 


7 


6 


5 


4 


3 


2 


1 


0 


S-Byle 1 


1 


S6 


S5 


S4 


S3 


S2 


SI 


SO 


X-Byte2 


0 


X6 


X5 


X4 


X3 


X2 


XI 


XO 


x-Bytc 3 


0 


X13 


X12 


Xll 


X10 


X9 


X8 


X7 


Y-Byte4 


0 


Y6 


Y5 


Y4 


Y3 


Y2 


Yl 


YO 


Y-Byte5 


0 


Y13 


YU 


YU 


Y10 


Y9 


Y8 


Y7 



55 



60 



65 



TABLE 2 



Format Tablet Status Bits 



Bit 



Description 



Values 



SO 
51 
S2-S4 
S5 
56 



Switch 1 status 
Switch 2 status 
Reserved 
Pen or Finger 
Proximity 



Not used 

0 ~ Switch is off. 

Not used 

1 = Whiteboard surface is being touched 
(a touch down or a continued touch). 

0 = Whiteboard surface is not being 
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TABLE 2 -continued 



Formal Tablet Status B its 
Bit Description Values 5 

touched (a touch lift off or inactive). 

When the proximity bit changes from 1 

to 0 (touch lift off), one final set of X, Y 

coordinate data is output with the 

proximity bit equal to 0 and the X, Y 10 

coordinate data equal to the last touch 

point. 

S7 Packet Always 1. 

Synchronization 



Get Parameter Block 

Description: Allows access to all power-up and run time 
parameters used by the controller. The Get Parameter 
Block (GP) command works in conjunction with the Set 
Parameter Block (SP) command. This pair of commands 
is used for configuration and diagnostic purposes. Param- 20 
eters are retrieved using command GP and modified in 
data blocks using command SP. The blocks include cali- 
bration and initialization data, linearization data, and run 
time variables. 

Mode Stream 25 
Syntax: <SOH>MS<CR> 

Description: Causes the controller to send a continuous 
stream of (X, Y) coordinate data when the whiteboard 
surface is touched. The controller continues to send data 
as long as the screen is touched. The controller sends the 30 
data even if the touch is stationary and unchanging. The 
format of the coordinate data depends on the last format 
command received by the controller. 
Response: <SOH>0<CR> Positive response. 

Null Command 35 
Syntax: <SOH>Z«CR> 

Description: Queries the controller and waits for a response. 
This command is used to determine if communication 
with the controller is established. Using this command 
does not affect the controller's current operating param- 40 
eters. 

Response: <SOH>0<CR> Positive response. 
Output Identity 
Syntax: <SOH>OI<CR> 
Description: Causes the controller to report a firmware 45 
identity string, which includes the controller type and the 
firmware version number. 
Response: <SOH>CcXxxx<CR> 
where: 

Cc=two ASCII characters that describe the type of 50 
controller. Ql=Scrial/SMT3 controller which is 
available from MicroTouch Systems. Inc., Methuen. 
Mass. 

Xxxx=Four ASCH characters that indicate the firmware 
version number in decimal format. The first two 55 
characters represent the version number; the last two 
characters represent the revision leveL For example. 
0100 means Version 1, Revision 0 (that is 1.0) or 
0510 means Version 5, Revision 1 (5.1). 
Reset 60 

Syntax: <SOH>R<CR> 
Description: Initializes the hardware and the firmware, 
causes the controller to stop sending data, and recalculates 
the environmental conditions (for example, stray and 
offset values). The Reset command also cancels the 65 
Format Raw and Calibrate Raw commands and returns 
the touch controller to normal operation. The computer 



10 

should preferably issue a Reset command whenever it is 
powered on and is attempting to establish communication 
with the touch controller. The Reset command may take 
up to 240 milliseconds (0.25 seconds) to execute. 
Therefore, the application program should wait at least 
250 milliseconds (and receive the command response) 
before issuing another command to the touch controller 
following the reset. 

Response: <SOH>0<CR) Positive response. 

Restore Defaults 
Syntax: <SOH>RTXCR> 

Description: Causes the touch controller to assume factory 
default operating parameters. The Restore Defaults com- 
mand copies the factory default parameters from ROM to 
the non-volatile memory (NOVRAM) and then executes 
a Reset command. Table 3 lists the factory defaults. The 
Restore Defaults command is useful in situations where 
inadvertent commands to the controller have rendered the 
whiteboard inoperative. 

TABLE 3 



Factory Defaults 



Parameter 



Data Format 


Formal Tablet 


Operating Mode 


Mode Stream 


Serial Strings 


N, 8, 1 


Baud Rate 


9600 


Auto Baud 


N/A 


Finger Mode 


Finger Mode 


Return to Factory 


Yes 


Calibration 





The Restore Defaults command requires approximately 75 
to 100 milliseconds, plus the execution time of the Reset 
command. Accordingly, the host application program should 
wait a minimum of 350 milliseconds (and receive the 
command response) before issuing another command to the 
touch controller. 

Response: <SOH><kCR> Positive response. 
Set Parameter Block 

Description: Allows access to all power-up and run time 
parameters used by the controller. The Set Parameter 
Block (SP) command works in conjunction with the Get 
Parameter Block (SP) command. This pair of commands 
is used for configuration and diagnostic purposes. Param- 
eters are retrieved (using GP). and modified (using SP) in 
data blocks. The blocks include calibration and initializa- 
tion data, linearization data, and run time variables. 

Unit Type 

Syntax: <SOH>UT<CR> 

Description: Causes the controller to report a controller 
identity string. This string identifies the type of controller 
currently attached to the system, lists the features sup- 
ported by the controller, and outputs the status of the 
touch controller hardware. 

Response: Returns an identification code up to 8 ASCH 
characters in the following format: 

<SOH>TTFff£Ss<CR> 

where: 

TT=Iwo A SCII characters that indicate the controller 
type, which preferably indicate a Serial/SMT3 control- 
ler available from MicroTouch Systems. Inc. 

QM=Serial/SMT3 controller 

Ffff=Four ASCD characters that indicate the features 
supported by the controller 
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Asterisks (****) indicate thai do additional features are 
configured. 

Ss=Two ASCU characters that provide status information 
about the touch controller hardware. The two charac- 
ters represent one byte. Each character is in the range 3 
0 to 9 and A to F. 
Tabic 4 defines the meaning of each bit in the status byte. 
Each bit can be set to 1 or 0. where: 
l=Error 
0=No error 

00=No diagnostic errors (normal response) 



10 



12 



files. INI files, or similar. The installation software provides 
all necessary functionality to install the driver and applica- 
tion onto the user's system including detection of a con- 
nected whiteboard and configuration of the communication 
port settings. 

The driver takes the form of a virtual device driver (VxD) 
which receives serial communications data from the white- 
board and passes the resulting assembled messages up to the 
application. The driver is loaded at Windows startup with the 
rest of the operating system. At this point, the driver is in 
memory, however, it does not communicate with the serial 
port or with the application. The application establishes 



TABLE 4 

Bit Definition for the Unit Type Command 



Bit Senal/SMT# Stilus 



ToucbPcn Status 



0 Reserved 

1 ROM error. Firmware checksum 
verification error. 

2 PWM error. Unable to establish 
PWM operating range at power 
up Noorecoverable error. 

3 NOVRAM error. Tbe operating 
parameters in the controller 
NOVRAM are invalid. Using 
defaults. 

4 HDW error. The controller 
hardware failed (unable to 
initially^ or configure gate 
array). Nonrecoverable error. 

5 Reserved. 



Cable error. The linearization 
Data in the cable NOVRAM 
is invalid. 

NOVRAM2 error. The 
linearization data in the controller 
NOVRAM is invalid. 



RAM error. Hardware malfunction. 
Same. 

Analog-to-digital (A/D) error. The 
A/D converter malfiirrrtmwl 

Same. 



ASBC error. Tbe Application 
Specific Integrated Circuit 
(ASIC) failed. 

Reset flag. 

1 - A Unit Type command has not been 

issued since the last reset 

0 = A Unit Type command has been issued 

Since tbe last reset. 

Reserved. 



Same 



IV. Desktop Software 

FIG. 4 of the drawings shows a block diagram of the 
interaction between the application software, shown at 64 
and the driver 62 The driver provides the necessary com- 
munications support to interface with the whiteboard 
through serial port 70 at tbe hardware layer of the PC and an 
appropriate API interface at the application layer of the PC 
as described in further detail below. The application soft- 
ware provides all the required functionality for the Graphic 
User Interface (GUI) and the file system. In a preferred 
embodiment, the application software operates under the 
Windows95 or the Windows 3.1 operating system in con- 
junction with the Win32s extensions, each of which is 
available from the Microsoft Corporation, Redmond, Wash. 
Various aspects of developing software to operate under the 
foregoing operating systems and to utilize the services 
provided by such systems are described in literature avail- 
able from the Microsoft Corporation. By way of example, 
the Visual C development environment available from the 
Microsoft Corporation may be employed to develop systems 
employing the features described herein. In the description 
which follows, numerous acronyms are used in connection 
with file types, services or protocols employed by the 
foregoing operating systems. Those skilled in the art will of 
course understand the meaning of such terms in the context 
of either of the foregoing Windows operating systems. 

Both the driver and the application may be made up of 
several individual components including DLL files. EXE 



communication with the driver through a protected mode 
APL The application can then send the driver commands to 
execute. The application begins by asking the driver to open 
the serial port connected to the whiteboard. The driver opens 
the serial port using VCOMM in Windows 3. 1 or (Windows 
3.11) and Window s95. In Windows 3.1 or 3.1L the driver 
does not open the serial port The driver next sets the serial 
port up to communicate with the whiteboard by changing the 
baud rate. etc. and disabling the serial port's interrupt Then 

so the driver installs an interrupt handler for the Real Time 
Clock (IRQ 8). 

The Real Time Clock, or KTC generates an interrupt 
approximately 1,000 times per second by default. The KTC 
can be set up via the computer's CMOS to run at different 

55 rates. The driver modifies the CMOS so that the FTC 
interrupt gets triggered at a rate of approximately 2.000 
times per second. Using this interrupt as a heartbeat, the 
driver polls the serial port to read data sent from the 
whiteboard. 

60 This whiteboard data is dealt with in a variety of ways, 
depending on how the application has instructed the driver 
to process it. There are several commands that determine 
how the data gets processed. For example, if the application 
sends the "start logging" command, the data will be returned 

65 to the application via a callback procedure. The callback 
procedure's address is passed to the driver when the appli- 
cation issues the "start logging" command. The application 
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could also tell the driver to use the data coming in from the set to one. Thus, the foregoing procedure advantageously 

whiteboard as input for the mouse by issuing a "set mouse reduces the chance of receipt of false information by the 

mode" command. driver in the case of noise which causes data to be lost over 

Advantageously, the driver employs polling rather than the serial link connecting the whiteboard to the computer. If 

interrupts to determining if data is available at the serial port. 5 information is ignored due to detection of an error, the driver 

The current standard for IBM compatible PCs is to share inserts a pen-up command at step 84 to reduce the possibility 

IRQ 3 and IRQ 4 between COMM ports 1 through 4. of streaking caused by possible loss of a packet containing 

COMM ports 1 and 3 typically share IRQ 4 and COMM a pen-up command. If the lost byte did not contain a pen-up 

ports 2 and 4 typically share IRQ 3. The IRQs are used to command then step 84 will cause a small discontinuity to 

signal a serial port that there is data incoming from an to appear in the image stored by the driver. However, this is 

external device. The problem with this is that IRQ sharing believed to be an acceptable trade-off for the alternative of 

works only if everything in the system agrees to share. If an missing a pen-up command which would cause the image 

application wants to take over IRQ 3 and not share it the stored in the PC to have a line connecting the point at which 

system will allow it. and sharing that IRQ will not be the lift-off which occurred and was not recorded to the point 

possible. Further, not just applications can be IRQ sharing 15 at which the next valid packet was recorded, 

unfriendly, but rnotherboards. COMM cards. Modems, or A t 85, the WB event is checked to determine if it is a 

any other serial device can set an IRQ to be non-shareable. special event and therefore requires immediate action and if 

These problems cannot be solved with software. Therefore. so. the driver at 88 generates a call-back to the application 

the ability for a serial communication application to work 64 to cause the action to be performed. Preferably all events 

properly will be highly reliant on the computer on which it 20 entered in the control region of the whiteboard are special 

is installed. Even if the machine that the application is events. Otherwise, at 87. the driver stores the event to a ring 

installed on is IRQ sharing friendly, there are other issues type of buffer (seen at 68 in FIG. 3) which is stored in shared 

matcomphcatefoenm^^ memory. In a preferred einbodiment. the driver simply 

two ports at once. If COMM port 2 is being used at the same distinguishes between data generated at the whiteboard to a 

time COMM port 4 is being used, and the ports share IRQ 25 sufficient extent to determine if the data is entered in the 

3. the ports wfll get notified at a much slower rate. This can writing region, or if the data is entered in the control region 

lead to data loss from the UAKT and other timing issues that and if so, if the data entered in the control region requires 

might interfere with both communication operations. immediate action. Actual recognition of and action on the 

The polling method is advantageous because the driver event is performed by the application 

T^J^^^^t DOt S C ^ff 30 Periodically, if the ring buffer contains a Redetermined 

2J£ t / - E ^ 15 tl^ le l^ d * y of data, the driv£ wfll generate a callback for the 

disabling the interrupts on the serial port being used by the o««ii~>#;~« * A _ _* . . 

. : . . ° a *u a - -a „ JT application to retrieve the information stored in the nne 

I t ^"k *?? T 00 "» rc "«* of * e events whichrequie irametote action are the Plint Wit 
^ dev,^ attached to the system. Another benefit is that 35 aod ^ evenL ^ ^cation anS 

"ff* w "f senal <* ^ * e communicate with one another bypassing message?^ 

SSoid OM aVaUaWe ^ ** «"**>Be queues (seen in FIG. 4 at « and 63) assliated 

rpt Awi * i — respectively with the application and driver 
The driver also supports an appropriate API (as described JL~ ..; . . T . . 

below) to receive messages from the application and trans- 40 w ^ wh J teboard application interacts with the controller 

rait that data in serial form back to the whiteboard. Hie by Wa * of a ****** JSbat y of mterfacc routincs im P [t ' 

driver supports interrupt sharing to the extent that another mc ?? d by * e dnVer which P™** a sct of commaDds to 

serial device driver such as a mouse or modem driver can «^ by me oriver to make use of the input capabilities of the 

also receive communications data using the same assigned whitebo ^ d W. In accordance with the invention, a wide 

interrupt 43 vm ^ ofa PPk<^ on F°graiiisinaa^^ 

At predetennined intervals, which in a preferred embodi- l l 0gram ^^ed herein can thus be written to make 

meat is approximately 500 microseconds, the driver 62 polls cff «* vc use of the touchscreen u sing a standard set of easily 

the serial port to sec if information is at the serial port of the "nderstocKl Application Program Interface (API) function 

PC which is connected to the whiteboard and performs the J** wmch TZ conveniciltl y expressed in the same 

functions shown in FIG. 6. As seen in FIG. 6. at 80 the 50 laDgUagC used mc ^cation programmer for conven- 

driver receives whiteboard events in the form of graphical ^ P™* 8 ™"*** ™* " which the API function 

user inputs entered in writing region 18 and specialTvents calls may be made as weU as the functions performed and 

entered via button region 20 through serial port 81. At 82, ^"Tsh y unction calls is explained in 

the driver checks the received packet to determine the below: 

presence of errors in the five bytes of the packet As 55 Application to Driver Communication 
previously noted in connection with the description of the The application sends requests to the driver via a routine 

Format Tablet command, the five-byte packet is coded such known as the Protect Mode API routine. The application 

that the first bit of the first byte is always set to a one value must be running in a 16-bit environment to access the 

and the first bit of the remaining four bytes is set to a zero routine. This means that a 32-bit application will need to 

value. If a byte is received in which the first bit is set to one, 60 thunk down to a 16-bit DLL in order to communicate with 

the next four bytes received should each have the first bit set the VxD. 

to zero in order for the packed to be considered a valid The following code may be used to retrieve the driver's 

packet If a byte is received in which the first bit is set to one Protected Mode API routine address. This code must be in 

and the next four bytes do not start with a zero, then the byte a 16-bit code segment The following notice applies the code 

with the first bit set to one and the succeeding bytes are 65 contained herein: Copyright 1996, MicroTouch Systems, 

ignored (step 83) until the next byte received has the first bit Inc. 
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static BOOL GetVxDAPDfandler (void) 
\ 

char *3xEnor = NULL; 

WORD wError = 0; 

/• get API entry to Ibid - if it is installed •/ 



_asm 






i 

mov 


ax. 1600b 


; enhanced mode? 


int 


2Fh 


; apt caD 


test 


al, 7Fh 


; enhance mode running? 


jz 


nnt ntrniin£ rhhanrwi 


; no 


mcrv 


ax, 1684b 


; get device API r^ll 


mov 


hi, MTWBS_DEV_JD 


; for the driver 


int 


2Fh 


; fet api entry point 


mov 


word ptr MTWBS_APL di 


; save the callback address 


mov 


word ptr MTWBS_API + 2, es 




mov 


ax, « 


; ts the application Instilled? 


OT 


ax, ax 




jnz 


vxd_ins tailed 




mov 


ax, di 




ar 


ax, ax 






vnl_jx>t_ installed 


; if not, split 


mov 


wError, 3 


; if only es is 0 then memory error 


jmp 


get__out 




vxd_installed: 






mov 


wError, 0 


: show success (PHERR_NOERROR) 


jmp 


get_out 








mov 


wEtror, 1 


; no enh windows! (PHERR_J^0386ENH) 


jmp 


get_out 


; return our error code 


vxd__DoeJnstaUed: 




mov 


wError, 2 


; Ibid? (FHERR__NOVPOSTD) 



get_out: 

/• error checking and reporting •/ 
if (wError — 1 ) 

szError = "RUN ENHANCED WINDOWS!"; 
else if ( wError — 2) 

szError = "INSTALL Ibid. VxD HRSTT; 
else if ( wError = 3) 

szError = "MEMORY ERROR! Could not load Ibid .VxD" 
if (wEnor) 
< 

MessageBoi( NULL, siEnor, "VxD TESTEXE", MB_OK ); 
return ( FALSE ); 

) 

return ( TRUE ); 

\ 



Calling the Driver 

The driver provides one interface similar to SendDriver- 
M ess age to specify a driver command and the parameters for 
the command. The API for mis function is: 



45 



static LRESULT CaHVxDAPIService(WORD ApL-Selectox, 
LPARAM lParaml, LPARAM lparam2); 



This routine passes data via registers. The following code is 
used to call the driver from the application. 



stalk; LRESULT CaUVxDAPIService(WORD ApL-Sektctor, LPARAM lParaml, 
LPARAM lParam2) 

\ 

LRESULT dwReturn = 0; /* assume the worst */ 

/* saury check */ 
if ( MTWBS_API ) 
< 

asm 

< 

push ax 
push bx 
push cx 
push dx 
push di 

mov ax, Api_ Selector ; tunc to call 

mov bx, word ptr lParaml ; load lParaml in to registers 
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mov cx, wort ptr IParaml + 2 

mov dx, word ptr lParun2 

mov di, wort ptr lParam2 + 2 

call dword ptr |MrWBS_API| 

roov word ptr dwRcmm, ax 

mov wort ptr dwRetura + 2, dx 

pop di 

pop dx 

pop cx 

pop bx 

pop ax 



) 

) 

/• return the result */ 
return ( dwRetura ); 



; load IParaml in to registers 

; call the VxD API Service 

; sniff the return value 
; stuff the return value 



The Driver Protected Mode APIs 

The commands that the driver responds to are listed below 
with a description of each command, the command's 
parameters, and the expected return values: 
MTWBCMD _NOP 

This command is the ID used in the MTWBCMD_ 
GetVxdVersion command to get the driver's version number 
without a command tag specification, and should not be 
passed to the driver 
MTWBCMD_GetVersion 

Gets the firmware (which is the code executed by the 
controller) version number. This command can only be 
executed after the port has been opened with either (he 
NfTWBCMD_OpenCommPort or the MTWBCMD_ 
OpenCornrnPortEx commands. 



IParaml ignored 
lParam2 ignored 
Returns: 

The version number of the driver on success 

0 if me Version Number has not been returned 
from the firmware. The driver will 

notify the application when the data has been 
received via the Message Callback 

1 on failure. 



NOTE: The MTWBCMD_GetVersion. MTWBCMD_ 
GetWhiteBoardlnfo. MTWBCMD_GerTimeout, and 
MTWBCMD_SetTimeout commands are sent to the firm- 
ware when the driver receives either the MTMTWBCMD_ 

OpenComrnPort of the MTWBCM D Open Co m mP nrtRY 

commands. Because these commands require immrHjate 
feedback from the driver, the driver attempts to obtain the 
data as soon as possible. It is possible for any one of these 
commands to be issued before the driver has received the 
data from the whiteboard because of the delay in receiving 
data from the whiteboard. In this case, the driver will return 
0 to tell the application that it should wait for a notification 
from the driver that the data is ready. Once the application 
receives the notification, ft can call the driver to obtain the 
information. If the driver detects that the whiteboard is 
disconnected from the serial port, then these commands will 
return -1. 

MTWBCMD _SetLoggingMode 

This command tells the driver to start logging data 
received from the whiteboard attached to the sensor identi- 
fied by IParaml by calling the callback provided in IParam2. 
The serial port does not need to be opened to use this 
command, but the data will not be logged until the port is 
opened. 



IParaml contains the sensor number. 0 through 4 (where 
20 0 is interpreted as 1) lParam2 contains a far pointer to the 
callback routine in the application 
The callback function prototype is: 



long PASCAL White boordCilIbackEx(tot\g togHandle, ToucbPacket FAR 
MpPacket); 



The TouchPacket FAR* parameter points to the following 
structure of: 

30 



35 



struct ToucbPacket 




< 

WORD wTabletX; 


// X location 


WORD wTabletY: 


//Ytocatkm 


WORD wState; 


// Tablet packet header 


WORD wRepCocnl; 


// repeat count ~ discarded packets + 1 



The callback must be located in a locked code segment. It 
cannot call any Window's API calls except for the PostMes- 

40 sage routine. It cannot access anything but locked data. 
The first time the driver calls the callback, it passes NULL 
for the logHandle. This tells the application that it should 
return the logHandle identifying which whiteboard the pack- 
ets belong to. No processing of the packet is done this first 

45 time. Every other time that the driver calls the callback, the 
logHandle will be passed to identify which board the packet 
came from and the return value will be ignored. 



Returns: 

Sensor number - on success 

0. . on failure 



MTWBCMD_SetMouseMode 

This command is used to either query the driver to return 
the status of mouse mode or to turn mouse mode on or off. 
When mouse mode is on, the driver uses the touch packets 
that are being sent by the whiteboard attached to the sensor 
number passed in via TPaiaral as input for the mouse. 

IParaml the sensor Dumber to take the input from. 0 
through 4 (where 0 is interpreted as 1) lPram2 0=stop mouse 
mode. l=start mouse mode. 2=get mouse mode 
Returns: 



For lParam2 = ) or lPamn2 = 0 

TRUE - for success 
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-continued 



FALSE 
For lParsm2 = 2 
1 
0 



- for failure 



- for mouse mode ON 

- for mouse mode OFF 



MTWBCMD_StopLoggingMode 

This command tells the driver to stop logging data sent by 
the whiteboard identified in IParaml. 



IParaml Whiteboard Handle (returned from 

MTWBCMD_SedjoggiagMode) 
lParam2 ignored 
Returns: 

TRUE • on success 

FALSE - on faihre 



MTWBCMD_GctWhitcBoardInfo 

This command can be used to get several pieces of 
information about the setup of the driver and the whiteboard 
(s). This command can only be executed after the port has 
been opened with either the MTWBCMD_OpenComraPort 
or the MTWBCMD_OpenCorurnPortEx commands. 

IParaml the loword of IParaml specifies the type of 
information required, the hiword depends on the information 
requested 

lParam2 depends on the type of information requested. 
This command allows the user to request the following 
data by passing in the ID as the loword of IParaml: 



ID Data to be returned 

1 the size of the MTWB_£oanUxifb structure. 

2 the number of sensors attached to the controller. The driver 
gets tfri* number from the systcmjni file under the 

entry "NumberOfBoards" . 

3 the relative position of sensor 2. The driver gets this number from 
the systemini file under the entry ^LocatjouBoardr*. 

4 the MTWB^Boardmfo structure for the whiteboard 
attached to aensor 1. 

5 the MTWB„Boardlafo structure for the whiteboard 
attached to sensor 2. 



These Ids are represented by the following enurm 



MTWBS_JNFO { 

MTWBINFO_3oaniinfbSirc - I 

XfTWBINFO_3&iMboaniGetnum 

MTWBINFO _MuinbocirdPos 

VrrWBINFO_BoardiiifoGetl 

MTWBIWO_JfcardmfoGeU 

MTWBINFO__Last 



When the command is passed to the Driver with the loword 
of IParaml equal to 4 or 5. the hiword of IParaml and 
lParam2 are used. In both instances, the hiword of IParaml 
needs to contain the size of the buffer referenced by lParam2. 
LParam2 contains a pointer to the start of a MTWB_ 
Boardlnfo data structure. The hiword of IParaml contains 
the size of the buffer referenced by lParam2. The MTWB_ 
Boardlnfo structure is: 
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DWORD m_iRightDTOwStart; 
DWORD m__rropDrawStart; 
DWORD m_®ottomDrawStart; 
DWORD m_iBoardwidth; 
DWORD m_iBoardHeight; 
DWORD OL_ixKesohrtioD: 
DWORD rxL_iy Resolution; 
DWORD m_iTBDl; 
DWORD m_JTBD2: 



// futures 



10 K 

typedef struct CagBoardlnfD MTWB Boardlnfo; 

Returns: 

When the loword of lParaml=l 
15 The size of the MTWB_3oardInfo structure 
When the loword of lParaml=2 
The number of boards attached to the firmware (the 

default is 1) 
When the loword of lParaml=3 
20 The relative position of sensor 2 which can be one of the 
following values: 



enum XTTWBS_POSnTON { 
MTWBPOS_ Error 
MTWBPOS_3oard2IsBeJow 
MTWBPOS _Board2IsLeft 
MTWBPOS_BoardlIsAbove 
MrWBPOS_Board2IsRi g ht 
MTWBPOS_tast 



, //Error 

, // Board 2 below board 1 
, //Board 2 left of board 1 
, // Board 2 above board 1 
, // Board 2 right of board 1 
, // The first illegal value 
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The default value is MTWBPOS Jrror. 
When the loword of iParaml=4 or 5 
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The size of MTWB_^BoardInfb structure on success 
0 if the whiteboard information has not been returned bum the 
firmware. The driver will notify the application when the 
data has been received via the Message Callback 
-1 if the parameters are incorrect or if the whiteboard is 
disconnected 



struct taiBoardlnfo { 

WORD m_Size; 
structure 

DWORD m_iLeftDrawStart: 



f drivers idea of the size of this 



NOTE: The MTWBCMD_GetVersion, MTWBCMD_ 
GetWhiteBoardlnfo. MTWBCMD_Ge (Timeout, and 
NTTWBCMD_JSerTimeout commands are sent to the firm- 
ware when the driver receives either the MTWBCMD_ 

45 OrttnCornmPort or the MTWBCMD_OpenCominPortEx 
commands. Because these commands require immediate 
feedback from the driver, the driver must attempt to obtain 
the data as soon as possible. It is possible for any one of 
these commands to be issued before the driver has received 

50 the data from the whiteboard because of the delay in 
receiving data from the whiteboard. In this case, the driver 
will return 0 to tell the application that it should wait for a 
notification from the driver that the data is ready. Once the 
application receives the notification, it can call the driver to 

55 obtain the information. If the driver detects that the white- 
board is disconnected from the serial port, then these com- 
mands will return -1. 
MTWBCMD_SetSound 
This command is used to tell the driver to send a sound 

60 command to the firmware. This command can only be 
executed after the port has been opened with either the 
MTWBCMD_OpenCommPort or the MTWBCMD_ 
OpenCammPortEx commands. 

IParaml the ID of the sound command to send to the 

65 firmware 

!Parara2 ignored 
Oct, 4. 1996 



09/20/2002, EAST Version: 1.03.0002 



5.790.114 



21 



22 



The ID to pass in as IParaml comes from the following 
enum: 



enum MTWBSSOUND { 

KfTWB SO UND_Do Nothing, // do not send a sound command to 
controller = 0 

\TTWBSOUND_LoudCKck, 

MTWB SOUND _I<otidHum, 

MTWBSOUND_XoudBeep, 

MTWB SOUND_LoudF top, 

MTWB SOUND _LoudFanFare, 

MTWBSOUND_SoftClict 

MTWBSOUND_SoftHum ? 

MTWBSOUND_SoftBeep, 

MTWBSOUND_SoftFlop. 

MTWB SOUND_So ftFanFare, 

MTWBS0UND_0ukt, // make no sound when touched = S 
MTWBSOUND_iasJ //The first illegal ralue 

Returns: 

TRUE on success 

FALSE on failure 
NOTE: a success when sending a command to the white- 
board's firmware only means that the driver was able to send 
the command. It does not mean that the firmware will 
receive the command or act on it appropriately. 
MTWBCMD_SetEraseMode 

This command is used to tell the driver to cither set or turn 
off the erase mode flag in the sound command. The firmware 
uses a bit in the header of the sound command to determine 
if the board is in "Erase Mode." 



10 



15 



20 
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IParaml 


contains the tensor number, 0 through 4 




(where 0 is interpreted as 1) 


lParam2 


l=set erase mode, 0=stop erase mode 


Returns: 




TRUE 


on success 


FASLE 


on future 
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NOTE: a success when sending a command to the white- 
board's firmware only means that the driver was able to send 



of IParaml is the interval, in seconds, for the driver to wait 
between confirmation requests to the controller. The con- 
troller time-out value will be written to the controller's 
EEPROM making it persistent. The driver confirmation 
Interval is reset to the default value. 60 seconds, or to the 
value set by the *VerifyTIme" entry in the systenuni file 
each rime the driver is loaded Once the driver is issued either 
the MTWBCMD_OpenCommPort or the MTWBCMD_ 
OpenCommPortEx command, the driver attempts to read the 
Block 1 data from the firmware. If reading the Block is 
successful, then the confirmation interval is set to the 
VerifTime value contained in the Block 1 data structure. 
Returns: 

TRUE on success 

FALSE on failure 
NOTE: The MTWBCMD_Get Version. MTWBCMD_ 
GetWhiteBoardlnfo. MTWBCMD_GetTimeout. and 
MTWBCMD_SctTimeout commands are sent to the firm- 
ware when the driver receives either the MTWBCMD_ 
OpenCommPort or the MTWBCM D_OpenComjnPortEx 
commands. Because these commands require immediate 
feedback from the driver, the driver must attempt to obtain 
the data as soon as possible. It is possible fox any one of 
these commands to be issued before the driver has received 
the data from the whiteboard because of the delay in 
receiving data from the whiteboard. In this case, the driver 
will return 0 to tell the application that it should wait for a 
notification from the driver that the data is ready. Once the 
application receives the notification, it can call the driver to 
obtain the information. If the driver detects that the white- 
board is disconnected from the serial port then these com- 
mands will return -1. 

MTWBCMD_GetTimeout 

This command makes the driver read the Block 1 data 
from (he firmware to get the firmware time out value. This 
command can only be executed after the port has been 
opened with either the MTWBCMD_OpenCommPort or 
the MTWBCMD_OpenCommPortEx commands. 



IParaml 
IParaml 
Returns: 



ignored 



The firmware time out value on sucess 

0 if the time out infarmauoo has not been returned from the firmware. 

The driver will notify the application when the data has been received 

via the Message Callback 
-1 on future 



the command. It does not mean that the firmware will 
receive the command or act on it appropriately. 
MTWBCMD_JSefTlmeout 

The application can use this command to write a new 55 
tune-out value into the Block 1 of the whiteboard's firm- 
ware. This command should be used with caution as it 
overwrites Block 1 data. This command can only be 
executed after the port has been opened with either the 
MTWBCMD_OpenCommPort or the MTWBCMD_ 60 
OpenCommPortEx commands. 

IParaml ignored 

lParam2 the loword of lParam2 contains the firmware 
timeout the hi word of lParam2 contains the driver confir- 
mation interval 65 

The loword of !Param2 is the firmware time -out value in 
seconds. The value must be between 0 and 255. The hiword 



NOTE: The MTWBCMD GetVcrsion. MTWBCMD_ 
GetWhiteBoardlnfo, MTWBCMD_GetTimeout. and 
MTWBCMD_SetTimeout commands are sent to the firm- 
ware when the driver receives either the MTWB CM D_ 
OpenCommPort or the MTWBCM D_Ope nC ornmPortEx 
commands. Because these commands require immediate 
feedback from the driver, the driver must attempt to obtain 
the data as soon as possible. It is possible for any one of 
these commands to be issued before the driver has received 
the data from the whiteboard because of the delay in 
receiving data from the whiteboard. In this case, the driver 
will return 0 to tell the application that it should wail for a 
notification from the Driver thai the data is ready. Once the 
application receives the notification, it can call the Driver to 
obtain the information. If the Driver detects that the white- 
board is disconnected from the serial port, then these com- 
mands will return -1. 
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MTWBCMD_OpenCommPort 

This command tells the Driver to setup the COM port and 
take it over (in Windows 3.11 and above). The Driver also 
installs a Real Time Clock (RBC) interrupt handler. This 
command must be issued in order for the Driver to com- 
municate with the whiteboard 



IParaml 


ignored 


tParani2 


ignored 


Returns: 




TRUE 


on success 


FALSE 


oo failure 


MTWBCMD_CloseCommPort 




This command tells the Driver to release the COM port 


The Driver also uo-in stalls the RBC interrupt handler. 


IParaml 


ignored 


lParam2 


ignored 


Returns: 




TRUE 


on success 


FALSE 


oo failure 



MTWBCMD_SetLED 

The application can use this command to write a new 
value into the LED status byte. This command can only be 
executed after the port has been opened with either the 
MTVBCMD_OpenCommPort or the MTWBCMD_ 
OpenCommPortEx commands. 

NOTE: LEDs are not currently supported by the Hardware. 



lPsraml the sensor cumber of the whiteboard to change, 0 through 4 
(where 0 b interpreted as 1) 

lParam2 bward=pen ID or new value for the whole byte, hiword=the 
command subtype 

The command subtype can be one of the following Taluca: 

0 turn the bit sprffifVri in the toward off 

1 turn the bit specified in the loword on 

2 Get the entire byte to the value from the loword 
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Currently 



FALSE 
TRUE 
FALSE on failure 



MTWBCMD_Open CommPortEx 

This command tells the Driver to setup the COM port 
specified by IParaml and take it over (in Windows 3.11 and 
above). The Driver also installs a Real Time Clock (RBC) 
interrupt handler. This command must be issued in order for 
the Driver to communicate with the whiteboard. 
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IParaml contains the sensor number. 0 through 4 (where 
0 is interpreted as 1) 

IParaml contains a far pointer to the callback routine in 
the application 

The callback function prototype is: void PASCAL 
WhiteboardMessageCallback(long SensorNumber. long 
MsgCode); 

The message code can be one of the following values: 



enum MTWB_MESSAGE { 
MTWBMSO_NONE 
MTWBMSG_ERR_VERSION 
MTWB MSG_ER R_VTjn\J ALIZE_RTC 
MTWB MSQ_TIMEOUT 
MTWBMSG_DISCONNECT 
MTWBMSO_RECONNECT 
MTWBMSG_ERR__PORT_READ 
K1TWB MS G_ERR__PORT_ WRITE 
MTWBMSC__BR R_QUEUE_PUT 
MTWBMSG_ERR_QUEUE_GET 
MTWBMSG_ERR_INPUT_DATA 
MTWBMSG_WBrNFO_READY 
MTWB MSG _LAST 

Returns: 



Sensor number 
0 



on future 



MTVVBCMD_GetVxdVersion 

This command is used to get the version Dumber of the 
Driver and whether a particular command is supported by 
the Driver. 

IParaml is the number of the command to be checked 
lParam2 is a pointer to the command's tag 
LParaml can be one of the following values: 
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IParaml 
lParcm2 

Returns: 



TRUE 
FALSE 



COM port number 
IRQ number 



on success 
go failure 



enum MTWBS_COMMAND I 
40 MTWBCMD__NOP = -1 

MTWBCMD_GctInfo 
MTWBCMD_SetInfo 
MTWBCMD__GetName 
MTWBCMD_GetVet5ion 
MTWBCMI>_DisplayIiifo 
MTWBCMD_SetLoggingMode 
MTWBCMD_SetMouseMoO£ 
MTWBCMD_StopLo£gingMode , 
MTWBCMD_GetWhilcBoardInfo 
MTWBCMD_SetSound 
MTWBCMD_SetEraseMode 
MTWBCMD_SetTmaeout 
50 MTWBCMD_Ge(TaneouJ 

MTWBCMD_OpenCommPort 
MTWBCMD_CkMeConmiPart 
MTWBCMD_SetLED 
MTWBCMD_OpeaCommPorl£x 
MTWBCMD_SelMcssagcC allback 
55 MTWBCMD_GetVxdVeT5km 

MTWBQ^^RenwveMessageCallback 
MTWBCMD_Last 

}; 



MTWBCMD_SetMessagcCallback 

This command is used to setup a message callback into 
the application. The Driver uses this callback to report errors 
and to send the application messages. 



60 Use KfTWBCMD_NOP to get the Driver's version number 
without the need to specify a command tag. 
LParam2 can be one of the following values: 
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ftfcfine MTWBCMD. 
tfdefine MTWBCMD. 
#dcfinc MTWBCMD. 
^define MTWBCMD. 
^define MTWBCMD. 
ttttfine MTWBCMD. 
#de6no MTWBCMD. 
•define MTWBCMD. 
fldefine MTWBCMD. 
ttdefme MTWBCMD. 
#define MTWBCMD. 
tfdefme MTWBCMD. 
Wcfiar MTWBCMD. 
fcfcfine MTWBCMD. 
#defiw MTWBCMD. 
Wcfinc MTWBCMD. 
#demK MTWBCMD. 
ftdefine MTWBCMD. 
#defitts MTWBCMD. 
#define MTWBCMD, 
Returns: 



_TAG_GETtNFO 

_TAG_SETINFO 

_TAG_GETN AME 

_TAG_GETWB VERSION 

_TAG_DISPLAYINFO 

.TAG_SETLOGGINMODE 

_TAG_SETMOUSEMODE 

.TAG_STOPLOGGINMODE 

_TAG_Ut"J WHITEB OARDINFO 

_TAG__ SETS OUND 

-TAG_ SETER ASEMODB 

_TAG_ SETTIMEOUT 

.TAG_GETT£MEOUr 

.TAG_QPENC OMMPO RT 

TAG_CLOSEC OMMPORT 

TAG_SETLED 

.TAG_OPENCOMMPORTEX 

TAG_SETMES SAGBC ALLB ACK 

.TAG_GETVXD VERSION 

TAG_REMOVEMESSAGECAIXBACK 



(VOID FAR*) *Gednfo" 

(VOID FAR*) "Setlafo'* 

(VOID FAR*) -GetKamc" 

(VOID FAR*) "GetWbVeraian" 

(VOID FAR*) "Displaylnfo" 

(VOID EAR*) -SetLoggmsMode" 

(VOID FAR*) -SctMouseMode" 

(VOID FAR*) "SlopLojginsMode" 

(VOID FAR*) XSetWhiteBoartflnfo" 

(VOID FAR*) "SetSound" 

(VOID FAR*) -SetEraseMode" 

(VOID FAR*) "Sefllmeour 

(VOID FAR*) -GdTaDsoui" 

(VOID FAR*) -OpeuCommPort" 

(VOID FAR*) "CbseCommPorT 

(VOID FAR*) -SetLED" 

(VOID FAR*) "OpcnCcmmPoitBT 

(VOID FAR*) -SerMessageCanback" 

(VOID FAR*) T3etVxd\fereicir 

(VOID FAR*) -RerooveMessajeCaUback" 



version number if the command b supported (internal command tag for me specified 

number is the same) 
0 if command is not Exported 



MTWBCMD^RemoveMessageCallback 

This command tells the Driver to stop sending messages 
generated from the whiteboard identified in IParaml. 



lParaml Whiteboard Handle 

(returned bom MTWBCMD_SetMessageCa!Iback) 
lParam2 ignored 
Returns: 

TRUE - on success 
FALSE - on failure 



The Session File 

FIG. 5 of the drawings shows the format of the session 
file. The session file consists of three main elements: the file 
header 76 which describes the file; the index blocks 77 
which hold the entries that define the images; and the data 
blocks 78 which hold all the data used to generate the 
images, including the color and writing tool changes. The 
data blocks 78 and index blocks 77 are created as needed. 
The header block 76 provides general information that 
applies to the overall file, including the metrics of the 
whiteboard, the eraser sizes used in the file, the size of the 
snapshot bitmaps stored in the file, and the file identification. 
The size of the header is 1.024 bytes. There is only one 
header block per file. The index blocks contain index entries 
pertaining to each image in the file and special event 
identifiers. Each index block contains a header that describes 
the location of the next and previous index blocks. An index 
entry determines how the image was created, either via the 
snapshot button or erase-all button. The index entry contains 
the snapshot bitmap in compressed format, a variable length 
name of the image, the starting and ending location of the 
data in the file, the date and time it was created, along with 
other attributes. An index entry can vary in size, but the 
index blocks are set to 65.536 bytes. The size is larger 
because the snapshot bitmaps are stored in the index block 
The data blocks contain all the data used to generate the 
image. The data is made up of data points that are stored in 
a compressed format. There is an absolute point followed by 
relative points. This series of points makes up a vector. 
There are special event data items that signify a color or 
mode change. A data block is 4.096 bytes. 



Advantageously, the session file contains the information 
necessary to recreate the sequential and temporal relation- 
ships generated upon entry of information via the white- 
board. For example, each stroke entered upon the writing 
region, including eraser strokes is saved in the session file. 
30 together with the temporal relationships necessary to recre- 
ate each stroke. Thus, the session file allows the subsequent 
viewing and editing, stroke by stroke, of an image. Strokes 
with the eraser may be selected, viewed, and removed, as 
may strokes with a marker or the user's finger. In addition. 
35 storage of temporal information allows use of handwriting 
recognition software. Display of an image created on the 
whiteboard on a computer display may be performed by 
display of each stroke stored in the session file. Thus, a 
stroke with a marker is displayed in accordance with the 
40 color designated for that marker in the session file, and a 
stroke with an eraser is displayed in white in accordance 
with the width of the chosen eraser (narrow or wide). 
Application Component 
The application component provides all the functionality 
45 (not contained within the driver) to support the operation of 
the whiteboard. This includes GUI. file system management. 
API communications, process control, etc. 

At startup, the application runs minimized (default 
condition), or as the foremost window on the display 13 
50 (user selectable option). A pre-defined button (ShowBoard) 
is provided at the whiteboard to bring the minimized win- 
dow forward and display the current state of the recording 
process. The application responds to this button by restoring 
itself to primary focus and displaying the current board 
55 image as seen in FIG. 1. 

A logger function within the application receives streams 
of whiteboard events from the driver (the exact structure of 
the data is described above), representing the coordinates of 
the current writing activity of the user. Redundant points and 
60 superfluous points (i.e., closely spaced co-linear) are 
removed from the data stream by the driver prior to storage 
of the data to the session file, thus providing a limited zero 
loss data compression mechanism. For example, if the user 
presses and holds a finger or marker to the surface of the 
65 whiteboard at a particular point so as to cause repeated 
generation of the same data to indicate the action, the logger 
function will receive only the first instance of the data and 
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will record a value indicative of the number of times the 
point was repeated. In addition, if the driver receives a first 
coordinate and a second coordinate, within an adjustable 
range of the first coordinate, then the second coordinate will 
be discarded and only the first will be sent to the logger. 5 
Those skilled in the art in view of the present disclosure will 
appreciate that other methods may be employed to eliminate 
redundant and superfluous points. 

At predetermined times or events (defined by the user) the 
application inserts a bookmark into the data stream, effec- 10 
tively marking the current board state for review. The 
display application provides a snapshot view of each book- 
marked board state. The user may explicitly place a book- 
mark via a soft button. The application also provides appro- 
priate automatic bookmarks for events such as "erase all" as 15 
described further herein. 
Graphical User Interface (GUI) 

The application provides a true Single Document Inter- 
face (SDI) interface but also permits a split window capa- 
bility as described further herein. The window layout is 20 
similar to that shown in FIG. 1. The application provides 
three primary viewable elements in the SDI window: selec- 
tion view, snapshot list control and current board thumbnaiL 

The selection view is a sub-divided region of the appli- 
cation SDI and provides the primary means to view any 25 
snapshot within the current session file. The view region 
allows the image magnification to be adjustable from the 
view menu or toolbar buttons and its size is adjustable by 
moving of splitter bars. The aspect ratio of the viewed image 
is preserved (default) unless the user chooses otherwise 30 
through a preference setting. The default background color 
of the selection view is white with colored pen strokes. The 
width of the displayed pen strokes is adjustable by a user 
preference. The displayed and stored width of erase strokes 
are separately adjustable by a user preference. The selection 35 
view displays either a selected snapshot from the list control, 
or the current board image from the current board snapshot 

The current board view is also a sub-divipro region of the 
application SDI and provides the secondary means to view 
the current state of the whiteboard. The view size is adjust- 40 
able by moving the splitter bars, and the aspect ratio of the 
view is preserved (default) unless the use chooses otherwise 
through a preference setting. The default background color 
of the current board view is also white with colored pen 
strokes. The border of the view is an adjustable graphic 45 
representation of the actual whiteboard. The current board 
view is updated frequently to show substantially real-time 
drawing activity at the board. 

The snapshot list control comprises a third subdivided 
portion of the application SDI and provides the primary so 
means to sort and view the set of snapshots stored in the 
current session file. The snapshot list control size is adjust- 
able by moving appropriate splitter bars. The bitmap reso- 
lution of each snapshot remains fixed allowing more or 
fewer snapshots to be visible when the list control size is 55 
adjusted The default background color of the list control is 
dark gray and the default background color of each snapshot 
is white with colored pen strokes. The snapshots are select- 
able using standard Windows mouse and keyboard 
sequences. Selection options include one. several 60 
contiguous, several individual, or all. The meaning of this 
selection process changes for different desired actions in 
accordance with conventions imposed by the particular 
Windows operating system. For instance, if an image is 
dragged to another application, only the last selected image 65 
will be dragged to the other application. During a move or 
append, all selected snapshots are moved or appended in the 



114 

28 

order selected, and if copied to clipboard, and pasted, all 
selected snapshots reappear when pasted in the order 
selected. 

Scrollbars are provided as appropriate for navigating 
through the available list of snapshots. An editable name 
field is displayed along with each snapshot. By default, this 
field is initialized to the snapshot creation time and creation 
date. This time and date information is displayed using a 
small floating tool tip window when the mouse cursor rests 
over a snapshot. This feature allows the user to rename 
snapshots without losing access to the creation date infor- 
mation. The title bar of the snapshot list control displays the 
text * 'Saved Images: N" where **K" is the number of snap- 
shots. 

The GUI provides the necessary Object Linking & 
Embedding (OLE) functionality to allow a snapshot to be 
selected and dragged by the mouse into another open OLE 
aware application. This action results in the contents of that 
snapshot being pasted into the target application. The GUI 
also provides the necessary functionality to allow a snapshot 
to be selected and dragged by the mouse onto a desktop 
button or program icon (as appropriate) to launch the target 
program with a copy of the contents of that snapshot 

The GUI provides the necessary functionality to allow 
snapshots to be reordered and deleted within the list control. 
This user accomplishes this task by selecting the target 
snapshot and then either dragging it to the desired location 
within the list control or by pressing the "delete" key to 
remove it Deletion of multiple selected snapshots is also 
supported. By default, a dialog box is used to confirm a 
delete action. Deleted snapshots are not recoverable. 

The GUI provides the necessary functionality to allow 
users to temporarily hide selected snapshots. Hidden snap- 
shots remain book marked in the session file but they are not 
shown in the list control unless the view menu option to 
show hidden snapshots is enabled. In this case, hidden 
snapshots are shown with a special border to indicate their 
hidden state. 

The GUI preferably provides, the following menu items: 
File Menu 

The file menu provides options for new, open. save, save 
as. close, export image, print. Print Rreview, Print 
Setup, list of most recent previously opened files, exit.. 
The close function causes the current whiteboard file to 
be closed and a new untitled file to be created. 

Edit Menu 

The edit menu provides options for copy, append imagers) 
to ... , move image(s) to . . . delete, select all. hide, 
unhide, unhide all. snapshot options. When the current 
board has the focus: export copy, append image(s) are 
enabled and move imagers) to, delete and cut are 
grayed. The append imagers) to function takes the 
currently selected image and adds a copy of it with 
stroke context to the selected target session file. This 
operation (if successful) is then confirmed by a modal 
dialog box Morrning the user that the append was 
successful. When the current selection is the current 
board view, it becomes the current board view in the 
target session file. The current board in the target 
session file is preserved as a snapshot When the current 
selection is a snapshot or snapshots, the image(s) are 
copied into the target file and appear as the last snap- 
shots in the target file. The current board remains 
unchanged in the target file. 

The Move image(s) to function takes the currently 
selected image and adds a copy of it with stroke context 
to the selected target session file. Hie currently selected 
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image is then deleted from the current session file. This previous state of the application and file system when the 
operation (if successful) is then confirmed by a modal application is restarted after an abnormal process termina- 
dialog box informing the user that the move was tion. The default file for board data input is the last active 
successful. When the current selection is the current session file before the application was closed. The file 
board view, this function is disabled. When the current 5 format accommodates the following: (1) a vector list, con- 
selection is a snapshot or snapshots the image(s) are taming individual strokes written on the whiteboard; (2) 
copied into the target file and appear as the last snap- time stamping of written data; (3) resolution of at least 4000 
shots in the target file. The current board remains points in both X and Y dimensions; and (4) snapshot images 
unchanged in the target file. stored as bitmaps. 
The cut function allows the user to delete a selected 10 Session Fde Control Actions 

thumbnail and place it on the clipboard at the same The application preferably supports, the following user 

time. The cut function is disabled (grayed) if multiple initiated file control actions. 

thumbnails are selected. The cut function does not NEW — A new empty session file is created whenever the 

operate on the current board image. user selects "new" from the file menu. The current session 

View Menu 15 file is closed with a default book mark added to the end. and 

The view menu provides options for toolbar, thumbnail aU subsc q uent action goes into this new untitled file, 

list, status bar. current board, screen layout . . . hidden ^ user ls P ven me °P tion of or discarding 

thumbnails, zoom in. zoom out, unsaved changes m the current, to be closed session file. 

Help Menu Under default conditions, the current board image does not 

« . , * ■ . . , 20 carryover into the new file. However, an option may be 

The help menu provides options for index and about. „'ia~a t~ a ... » ^ 1- 

Toolbar Buttons provided to allow the user to change this default behavior 

using option settings. 

The GUI includes a moveable toolbar. Hie functions OPEN — A previously created and currently closed ses- 

supported by buttons include new, open, save, print, si on fo e is reopened for viewing and board data input The 

thumbnail, cut, copy, current board, slide view, regular # ^cnX session file is closed with a default book marked 

view .full screen, zoom in. zoom out. size to window, added to the end. and all subsequent board action go into this 

and context sensitive help. reopened file. The user is given the option of keeping or 

Status Bar discarding unsaved changes in the current to be closed 

The GUI includes a status bar which provides assistance session file, 

to the user by indicating the current state of the appli- 30 SAVE— This function permanently commits any unsaved 

cation and the creation date and time of a selected changes in the current session file. The changes include 

thumbnail. added, re- ordered, hidden, deleted thumbnails and any board 

The application supports printing of single and multiple drawing data since the last save, 

images (one per page) on any properly Windows configured SAVE AS— This function creates a complete copy of the 

color or monochrome graphics printer. Printing options 35 current session file and begins using the new copy for all 

include the current board image, a group of snapshot images further board and editing activity. Any unsaved changes in 

from a multiple selection or all images in the current file the current session file go into me newly created copy, not 

including the current board. the original file. 

A printing dialog box includes options to specify the page APPEND IMAGE TO— This function allows the user to 

header and footer by means of pull down menus and editable 40 append a copy of the currently selected image to the end of 

text boxes. Formatting of the header and footer may be another session file. 

accomplished by way of embedded control characters which MOVE IMAGE TO— This function allows the user to 

allow various format of date and time representative of append a copy of the currently selected image to the end of 

cither the current date and/or time or the creation date and another session file and then immediately delete the cur- 

or time. Other control characters allow specification of fonts. 45 rently selected image from the current session file, 

font attributes such as bold italics, and font size. The Data Preservation 

application provides a print preview screen with zoom A priority in the file system design is the preservation of 

controls to allow the user to preview the target print action. user whiteboard data. The design incorporates appropriate 

The GUI provides two levels of on-line user help: general redundancy techniques to ensure that minimal data is lost in 

searchable, and context sensitive. The GUI provides three 50 the event of system crashes, etc. An unsaved, untitled 

view selection buttons in the toolbar. These buttons provide session file is shadowed by a hidden temporary file to ensure 

the means to switch the GUI between a normal layout view. data recovery until the user actively decides to save or throw 

a full screen slide sorter view, and a full screen page by page away that new session file, 

(or slide by slide) view. Data Compression 

File System Management 55 The software is designed to use various data compression 

The application stores all board drawing and erasing techniques including run length encoding to minimize disk 

activity sequentially in a data file called a "session" file. space used by the session files. 

Only one session file is open at any time and all board Exporting Data 

activity is added to the logical (not necessarily physical) end The application supports three methods for exporting 

of that file. Management of this file is consistent with a SDI so data: Clipboard, file. OLE drag & drop. These include the 

product except where noted herein. This file contains all the ability to copy the current selected image to the cupboard 

necessary information to recall and view snapshots, and to and to export the current selected image to a graphic file, 

navigate between bookmarks stroke by stroke. The file Graphic formats for all three methods include at least bitmap 

system supports deletion, hiding, and re-ordering of thumb- (3MP) and Windows metafile (.WMF), 

nails. The file system is advantageously designed to mini- 65 Advanced Features 

raize the loss of data in the event of abnormal process The application supports a set of advanced features which 

termination. Temporary files and flags are used to restore the are disabled by default at normal installation. These features 



09/20/2002, EAST Version: 1.03.0002 



5.790.114 



31 



32 



are activated by some sort of selection within the Options 
dialog. Once enabled, these advanced features provide sup- 
port for the following functions as a minimum: 

a) Bookmark Editing — The ability to edit the properties of 

a bookmark through a dialog. 5 

b) Stroke Navigation — The ability to navigate through a Ale 
stroke by stroke and page by page using the arrow keys, 
page keys, and toolbar icons. 

c) Mouse Events — When enabled through a separate check 
box. this feature outputs mouse cursor movements and 10 
left mouse select messages from the whiteboard driver to 
the Windows OS. 

Optional Settings 

The application provides an "Options'* selection item 
from the edit menu mat will then produce a tabbed notebook is 
style scries of dialogs. The following parameters, as a 
minimum, are selectable: 



a) Preserve Board Drawing Aspect Ratio. 

b) Override Screen Saver On Drawing Activity. — The 
default value for this feature is enabled. 



20 



c) Save settings and screen layout on exit 

d) Select Marker and Eraser widths 

e) Override Pen widths 

f) Switch to default drawing mode.— This feature defines 25 
the number of minutes and seconds which should 
elapse before the drawing state of the board defaults to 
black pen. The default value should be 2:00 minutes. 

g) Bookmark after n idle minutes. — This feature is dis- 
abled by default 30 

h) Sounds. 

i) Show hidden images. 

^ j) Use previous file on startup.— This feature is disabled 

by default 35 
Pen & Eraser Width Settings 

As previously noted, the application supports user selec- 
tion of the pen and eraser widths. One width is supported for 
or all four pen colors. There is a separate defined width for 
the wide eraser and for the narrow eraser. The eraser widths 40 
are stored in the session file and are always displayed as they 
were recorded. The pen widths are also stored in the session 
file and are always displayed as they were recorded unless 
the user chooses a selection to override the displayed pen 
width values. The override does not affect the values pre- 45 
viously stored. 

When the user changes any width value, the change 
applies from that time forward in the recording process. 
There is no requirement to edit previously stored widths. 

It is to be understood that the specific mechanisms and 50 
techniques which have been described are merely illustrative 
of one application of the principles of the invention. Numer- 
ous modifications may be made to the methods and appa- 
ratus described without departing from the true spirit and 
scope of the invention. For instance, as shown in FIG. 7, the 55 
GUI may take other forms. In FIG. 7. the window 90 
advantageously displays the image 91 entered by the user 
upon the whiteboard 10. A plurality of thumbnail images, 
which are reduced versions of images entered via the 
whiteboard are shown at 92 and 93. The thumbnail image 60 
shown at 92 is representative of the image being displayed 
(the active image) by the viewer. Thus, in the example 
shown in FIG. 7. the thumbnail 92 is a reduced image of 
image 91 Any one of the thumbnail images such as 93 may 
be made the active image to replace image 92 by selection 65 
of the thumbnail image by well known technologies 
employed by users of the Windows operating system to 



select particular items. Additional thumbnails may be dis- 
played by use of the button images shown at 94. These 
burtons allow the user to cause the thumbnails shown at 92, 
93 to change in response to the particular button selected. 
For example, the user may move backward through the 
thumbnails to view thumbnail images created prior to the 
thumbnail currently displayed. The user may also move 
forward through the thumbnails to view only the most 
recently creates thumbnails. Thus, the thumbnail images and 
buttons 94 allow the user to rapidly retrieve and view a 
plurality of images, to select an image for further viewing, 
printing, manipulation, etc. 

Buttons 95 allow for viewing of sequences with a par- 
ticular active image. For example, each stroke of the marker 
24 may be replayed sequentially, to allow viewing of the 
sequence of strokes which caused generation of an image 
such as shown at 91 Thus by use of buttons 95. status 
corresponding to the active image may be added or removed 
thus allowing editing of the image. For instance, certain 
portions of the image 91 may be removed, and the resulting 
image displayed on the viewer may then be stored, printed 
or transmitted. 

In addition, the particular structure of the software 
described herein may also be modified within the principles 
of the present invention. For example, the functions per- 
formed by the application may be performed by a plurality 
of programs* such as a recorder program which executes on 
the PC to record all actions on the whiteboard and a viewer 
program which may be invoked from time to time to view 
and manipulate images recorded by the recorder. Functions 
performed by the driver and application may be reallocated 
in other ways also. 

Additional modifications will also be apparent to those 
skilled in the art in view of the disclosure contained herein. 

What is claimed is: 

1. A whiteboard comprising: 

a drawing area on the whiteboard's surface upon which a 
user may draw using a writing instrument of a type 
generally used with whiteboards; 

a plurality of touch-selectable control areas on the white- 
board's surface, the plurality including at least 

a first control area which, when selected, indicates a color 
and 

a second control area which, when selected, indicates a 
view mode; 

means, responsive to drawing activity by said user in said 
writing area for causing transmission of information 
representing said drawing activity to a computer, 

means, responsive to selection of said first control area for 
causing transmission of pen color information to said 
computer which is indicative of a pen color selected by 
said user for said drawing activity in said information 
subsequent to said selection; and 

means, responsive to selection of said second control area, 
for causing transmission of a command to said com- 
puter which causes said computer to display a current 
image made from said information on a display. 

2. A whiteboard as set forth in claim 1 further wherein 
said user may erase a drawing in the drawing area using 

an erasing instrument of a type generally used with 
whiteboards and the whiteboard further comprises: 
a third control area which, when selected, indicates an 

erase mode; and 
means, responsive to selection of said third control 
area, for causing transmission of a command to said 
computer to interpret subsequent said drawing activ- 
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ity as erasure of an area in said writing area and to 
respond thereto by erasing a corresponding area in 
said current image. 

3. A whiteboard as set forth in claim 2 wherein 

said third control area indicates a narrow erase mode 5 
when selected and said whiteboard further comprises: 
a fourth control area which, when selected, indicates a 

broad erase mode; and 
means, responsive to selection of said fourth control 
area, for causing transmission of a command to said JQ 
computer to interpret subsequent said drawing activ- 
ity as erasure of an area in said writing area, said 
computer interpreting said subsequent said drawing 
activity in said information as causing erasure of a 
larger area and a larger corresponding area than if 
said subsequent drawing activity had been subse- 15 
quent to selection of said third control area. 

4. A whiteboard as set forth in claim 1 further comprising: 
a fifth control area which, when selected, indicates a 

snapshot. 

means, responsive to selection of said fifth control area, 20 
for causing transmission of a snapshot command to said 
computer to cause said computer to store marker infor- 
mation which causes said computer to interpret a 
portion of said information designated by said marker 
information as comprising a snapshot image. 25 

5. A whiteboard as set forth in claim 4 further comprising: 
a sixth control area which, when selected, indicates a 

snapshot and erasure of a display of said current image; 
and 

means, responsive to selection of said sixth control area, 30 
for causing transmission to said computer of said 
snapshot command, and for causing transmission to 
said computer of a command which causes said current 
image to be entirely erased in said display. 35 

6. A whiteboard as set forth in claim 1 further comprising: 
a seventh control area which, when selected, indicates that 

said drawing activity being displayed in said display is 
to be printed on a printer accessible from said com- 
puter; and ^ 
means, responsive to selection of said seventh control 
area, for causing transmission to said computer of a 
command which causes said computer to cause printing 
of an image corresponding to said current image. 

7. Apparatus for responding to first inputs received from 4J 
a touch sensitive white board and second inputs, the white- 
board having a drawing area on the whiteboard's surface 
upon which a user may draw using a writing instrument of 

a type generally used with whiteboards and a plurality of 
touch-selectable control areas on the whiteboard's surface, 30 
the control areas including at least a view mode selection 
area, a color selection area, and a print selection area, the 
apparatus comprising: 
means for causing generation of a window for display on 
a display responsive to said apparatus, said window 55 
including a current board region which contains a 
current image corresponding to current drawing inputs 
of the first inputs by a user upon said drawing area of 
said whiteboard, a snapshot region which contains a 
plurality of snapshots viewable by said user, each of 60 
said snapshots representative of past drawing inputs on 
said drawing area of said whiteboard, and a selection 
region which shows a snapshot image corresponding to 
a snapshot selected by said user from said snapshot 
region; ^ 
means, responsive to user size change inputs of the second 
inputs, for causing the size of said current board region. 



said snapshot region and said selection region to be 
changed in accordance with said user size change 
inputs; 

means, responsive to an input of the first inputs entered in 
said view mode selection area for causing said window 
to be displayed as a foreground window on said com- 
puter screen; 

means, responsive to an input of the first inputs in said 
color selection area, for causing storage and display of 
subsequent said current drawing inputs in a color 
selected by said input in said color selection area; and 
means, responsive to a print selection input of the first 
inputs in said print selection area, for causing printing 
of said current image. 
8. Apparatus for responding to first inputs received from 
a touch sensitive white board and second inputs, the white- 
board having a drawing area on the whiteboard's surface 
upon which a user may draw using a writing instrument of 
a type generally used with whiteboards and a plurality of 
touch-selectable control areas on the whiteboard's surface, 
the control areas including at least a display mode selection 
area, a color selection area, and a print selection area, the 
apparatus comprising: 
means for storing current drawing inputs of the first inputs 
by a user upon said drawing area to a computer file, and 
for periodically storing time stamps in said file to 
provide an indication of a date and time at which said 
current drawing inputs are stored to said computer file; 
means, responsive to control area inputs of said first 
inputs received from said touch-selectable control 
areas, for causing display of a current image corre- 
sponding to said current drawing inputs in a graphical 
window on a display responsive to the apparatus, and 
means responsive to a subsequent user generated view 
input of said second inputs for causing enlargement of 
said window, comprising. 

means responsive to a color selection control area 
input, for displaying an image corresponding to 
subsequent current drawing inputs in a color corre- 
sponding to said color selection control area input; 

means responsive to a wide erase control area input for 
causing existing current drawing inputs to be erased 
in accordance with subsequent current drawing 
inputs; 

means responsive to a narrow erase control area input 
for causing existing current drawing inputs to be 
erased in accordance with subsequent current draw- 
ing inputs, said narrow erase input causing erasure of 
said existing current drawing inputs along a path 
which is narrower than said erasure caused in accor- 
dance with said wide erase input; and 

means, responsive to an erase board control area input 
for causing all existing current drawing inputs to be 
erased; 

means, responsive to a bookmark control area input for 
causing a bookmark to be stored in said computer file 
among said drawing inputs; 

means, responsive to a print control area input for caus- 
ing said apparatus to transmit to a printer data for 
causing said printer to print said current image; 

means, responsive to a retrieve input of the second inputs, 
for causing display of an image corresponding to said 
drawing inputs which are stored between a pair of said 
bookmarks; and 

means, responsive to initiation of said means for causing 
display of said current image, for causing a plurality of 
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thumbnail size images of sets of prior drawing inputs, 
each of said sets comprising drawing inputs which are 
stored between a pair of said bookmarks, to be dis- 
played in said window. 

9. The white board set forth in any one of claims 1 through 
6 wherein: 

said surface of said whiteboard is touch-sensitive. 

10. A touch-sensitive whiteboard which may be coupled 
to a computer that has a display and that responds to inputs 
from the whiteboard, the white board comprising: 

a drawing area on the whiteboard's surface upon which a 
user may draw using a writing instrument of a type 
generally used with whiteboards; 
a plurality of touch-selectable control areas on the 

whiteboard's surface, the plurality including at least 
a first control area which, when selected, indicates a 

color and 

a second control area which, when selected, indicates a 
view mode; and 

means for causing transmission of positions of touch 
inputs to the computer the computer responding 
when the whiteboard is coupled thereto 

to a touch input positioned in the first control area by 
associating the color indicated by the first control 
area with subsequent touch inputs in the drawing 
area and 

to a touch input positioned in the second control area by 
displaying a current image made using touch inputs 
from the drawing area. 

11. The whiteboard set forth in claim 10 wherein 

the user may erase what has been drawn in the drawing 
area using an erasing instrument of a type generally 
used with whiteboards; and 
the whiteboard further comprises: 

a third control area which, when selected, indicates an 
erase mode, the computer responding to a touch input 
positioned in the third control area by interpreting 
subsequent touch inputs as erasures of an area in said 
writing area and erasing a corresponding area in the 
image. 
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12. The whiteboard set forth in claim 11 wherein 

the third control area indicates a narrow erase mode when 
selected; and 
the whiteboard further comprises: 

a fourth control area which, when selected, indicates a 
broad erase mode, the computer responding to a touch 
input positioned in the fourth control area by interpret- 
ing subsequent touch inputs as erasures which are 
broader than erasures made in response to selection of 
the third control area. 

13. A whiteboard as set forth in claim 10. the whiteboard 
further comprising: 

15 a fifth control area which, when selected, indicates a 
snapshot the computer responding to a touch input 
positioned in the fifth control area by storing a 
sequence of the touch inputs for use in making a 

20 snapshot image. 

14. A whiteboard as set forth in claim 13. the whiteboard 
further comprising: 

a sixth control area which, when selected, indicates a 
snapshot and erasure of the current image, the cora- 
25 puter responding to a touch Input positioned in the sixth 
control area by storing a sequence of the touch inputs 
used to make the current image for use in making a 
snapshot image and deleting the current image from the 
display. 

30 15. A whiteboard as set forth in claim 10 further com- 
prising: 

a seventh control area which, when selected, indicates that 
the current image is to be printed, the computer 
33 responding to a touch input positioned in the sixth 
control area by causing the current image to be printed 
on a printer accessible to the computer. 

* * * * * 
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